Product documentation
This section describes how Service Tasks are created, prepared, executed and completed within HSO Service Management. It covers the Service Task lifecycle, Event Codes, work forecasts, labor and material registration, Service Operations, resource requirements and the integration with Microsoft Dynamics 365 for Finance and Operations and Mobile Field Service.
Introduction
A Service Task represents a specific unit of work performed as part of a Service Call. While the Service Call manages the overall service request, Service Tasks provide the operational and financial details of the work required to complete it.
Service Tasks can be assigned to field technicians, workshop employees, engineers or other service resources. A Service Call may contain multiple Service Tasks, but a Service Task cannot exist without a parent Service Call.
Operational information
A Service Task contains the information needed to prepare and execute the work, including the Service Object, Event Code, estimated duration, resource requirements, forecasted transactions and Service Operations.
During execution, actual hours, items, expenses, travel, operations and revenue can be registered against the task. These registrations are processed through the associated service project.
Service Task and Service Call relationship
Each Service Task is linked to a single Service Call and Service Object. Multiple Service Tasks can be used when a service request requires separate activities, visits or resources.
The Service Task maintains its own execution status, while the Service Call tracks the overall progress of the request. Changes in Service Task status can also trigger automatic Call Status updates when configured.
Introduction
Service Tasks are created from an existing Service Call. A task can also be created from another Service Task, retaining the relationship with the same parent Service Call.The selected Event Code determines which predefined work information can be applied to the new task.
Creating a Service Task
To create a Service Task:
Open the relevant Service Call and select the action to create a new Service Task.
Select or confirm the Event Code. Depending on the configuration, an Event Code may already be defaulted.
Review the task information inherited from the Service Call, including the Service Object and project context.
Review the generated forecasts for hours, items, travel, revenue and Service Operations, where applicable.
Save the Service Task to assign its Task ID.
A newly created Service Task starts in Quotation status.
Default work information
When the Event Code is selected, the system can populate the Service Task with predefined work information based on the combination of Object Type and Event Code. This may include estimated labor, required materials, Service Operations and revenue lines. The available defaults depend on the configured work package.
Introduction
Unlike Service Calls, which use configurable Call Statuses, Service Tasks follow a fixed set of seven statuses. These statuses control the progression from preparation and planning through execution, registration and completion.
Service Task statuses
| Status | Description |
|---|---|
| Quotation | The Service Task has been created and can be prepared or quoted. |
| Confirmed | The work is confirmed and ready for scheduling. Forecasted transactions are available without a specific resource or time reservation. |
| Scheduled | The Service Task has been assigned a planned time slot and resource, with the corresponding capacity reservations. |
| In process | Execution has started and actual work can be recorded. |
| Registered | Actual transactions have been registered and may still require review or further registration. |
| Ready | The task has been realized and its transactions posted as actuals, making applicable transactions available for invoicing. |
| Cancelled | The task has been cancelled, subject to the restrictions associated with reservations and registered transactions. |
Status transitions
Service Task statuses reflect the operational and transaction-processing stages of the work. Confirming a task prepares it for planning, scheduling establishes the resource and time allocation, and execution statuses support the registration and posting of actual work. A Service Task can have multiple registration records, for example when several technicians report their work separately.
Cancellation
A Service Task cannot always be cancelled or deleted. In particular, existing capacity reservations and registered or posted transactions restrict cancellation. Once a task has progressed beyond its initial preparation stage, cancellation is generally preferable to deletion where the system permits it.
Introduction
Event Codes identify the type of work to be performed on a Service Task. They provide the connection between a generic service activity and the work package configured for a particular Object Type. An Event Code can be used across different Object Types, while the associated work package may differ depending on the Service Object being serviced.
Object Type and Event Code
The Event Code itself identifies the service activity. The combination of Object Type and Event Code defines the applicable work package. This relationship can contain the estimated duration, Service BOM, item usage, Service Operations, revenue information and resource requirements. An Event Code must be available for the relevant Object Type to be selected for that Service Object.
Work package defaults
When a Service Task is created, the configured work package can provide the initial forecast and operational instructions. For example, an inspection Event Code may provide a set of measurements and checks, while a repair Event Code may provide estimated labor and required replacement parts. These defaults form the starting point for preparing and executing the Service Task.
Introduction
Service Task forecasts represent the expected work and transactions before execution. They support preparation, resource planning, material requirements and the financial estimation of the service activity. Forecast information can be generated from the selected Event Code and its Object Type configuration.
Forecasted transactions
A Service Task can contain forecasts for several transaction types:
Hours: estimated labor required to perform the work.
Items: expected spare parts and consumables.
Expenses: anticipated service-related costs.
Travel: expected travel-related transactions.
Revenue: predefined fees or other revenue amounts.
The actual forecast depends on the configured work package and applicable Service Management settings.
Forecasts and actuals
Forecasts describe the expected work, while actual registrations record what was performed. During execution, actual hours, materials and other transactions are recorded against the Service Task. These transactions are processed through the service project and can be compared with the original forecast.
Introduction
Service Tasks provide the operational basis for registering the resources and transactions used during service execution. Registrations are linked to the Service Task and processed financially through the associated project in Microsoft Dynamics 365 for Finance and Operations.
Labor registration
Actual labor is registered against the Service Task using hour transactions. These registrations identify the work performed and provide the basis for project cost and, where applicable, customer invoicing. The financial treatment of registered hours depends on the Project Integration and applicable invoicing conditions.
Material registration
Materials and spare parts used during service execution are registered as item transactions. The Service Task can contain forecasted item usage and a Service BOM. The Service BOM provides a predefined list of relevant parts that can be transferred to the task's item lines. Item processing uses the corresponding Microsoft Dynamics 365 for Finance and Operations inventory and sales order functionality, including picking and packing where applicable.
Expenses, travel and revenue
In addition to labor and materials, Service Tasks support the registration of expenses, travel-related amounts and revenue. Travel charges can be determined through the applicable visit tariff configuration. Revenue lines can represent predefined service fees or other amounts associated with the work. The resulting transactions follow the financial rules defined by the Service Call's Project Integration.
Introduction
Service Operations define the specific checks, measurements and actions that must be performed during a Service Task. They provide structured work instructions and allow the results to be recorded against the relevant Service Object or Component.
Service Operation types
HSO Service Management supports several types of Service Operations:
Check: records a result against configured reference values.
Measure: registers a numeric measurement and evaluates it against defined limits.
Counter readout: records a meter or counter value.
Calibrate: records calibration results against configured values and tolerances.
Exchange: records whether a component or part has been exchanged.
Operation: records whether a general activity has been performed.
Operation registration
Service Operations can be added to a task through the configured Event Code or maintenance process. They can also be added manually. During execution, the technician records the applicable return value or completion information. The registration identifies whether the operation has been executed and, where applicable, whether the result is within the configured limits.
Operational history
Registered Service Operations are retained as part of the Service Object's service history. The results can be reviewed from the Service Task, the Service Object's configuration and the registered operations inquiry. This provides a historical record of inspections, measurements, calibration activities and other completed work.
Introduction
Service Tasks can record information about the condition and usage of a Service Object, including meter readings and activities performed on its Components. This information supports service history and usage-based maintenance processes.
Counter readouts
Counter readouts register a dated value against a meter or counter associated with the Service Object. These readings are retained as history and can be used by meter-based maintenance functionality. Where applicable, a reading can be marked as verified.
Component-related operations
Service Operations can be associated with Components of the Service Object. This allows measurements, checks and other activities to be recorded against the relevant part of the serviced equipment. Exchange operations can also record whether a component replacement activity was performed. Detailed information about Service Object structures, Components and meters is provided in the Service Objects chapter.
Introduction
Service Tasks can contain resource requirements that help determine which employees or other service resources are suitable for performing the work. These requirements are part of the task preparation and scheduling process.
Resource requirements
Resource requirements can be defined as part of the Object Type and Event Code work package. Together with the estimated duration, they provide information used when assigning Service Tasks to resources. Actual resource availability and assignment are handled through the scheduling functionality, which is described in the Planning & Scheduling chapter.
Mobile Field Service
When Mobile Field Service is used, Service Tasks can be made available to technicians through the mobile application. Confirmed tasks may be available as unassigned work, depending on the configuration. Scheduled tasks are made available to their assigned technicians. The mobile application supports the registration of work performed in the field, with the resulting information integrated into the Service Task process.
Introduction
Completing a Service Task involves registering the actual work, processing the relevant transactions and moving the task to its final operational status. The Service Task is the point where operational work is registered, while the related Service Call provides the context for overall service completion and invoicing.
Execution and completion
The standard process for completing a Service Task consists of the following steps:
Create the Service Task and review its work package and forecasts.
Confirm the task when the work is approved for execution.
Schedule the required resources and time slot.
Start execution and register the actual work.
Record labor, materials, expenses, travel and Service Operation results as applicable.
Review and process the registrations.
Realize the task and move it to Ready status.
The exact activities depend on the work being performed and the applicable configuration.
Project transactions
Service Task transactions are processed through the project structure associated with the Service Call and Service Object. The Project Integration determines the applicable project categories, line properties and financial treatment of the registered transactions. When the task reaches Ready status, its transactions have been processed as actuals and applicable amounts can be included in the subsequent invoicing process.
Service Call completion
A Service Call may contain multiple Service Tasks. Each task is completed individually, and all associated tasks must reach Ready status before the Service Call can be closed through the standard closing process. Where automatic Call Status updates are configured, Service Task status changes can also advance the parent Service Call.
Invoicing
The Service Call, rather than the individual Service Task, is the entity used for service invoicing. Transactions originating from one or more Service Tasks are processed through the associated projects and included in the Service Call invoicing process according to the applicable financial configuration. Detailed information about project postings, invoicing and financial adjustments is provided in the Invoicing & Financial Integration chapter.